I was surprised by these suggestions, in that objects drawn with an arithmetic transfer mode won't use the correct matched color. When I questioned his advice, he said that DrawMatchedPicture works fine for object-based material, and it calls CMMatchColors in the CMM. If, however, the source picture contains a pixmap, ColorSync converts it little-by-little into RGBColors and calls CMMatchColors on those bits before converting them back into a pixmap and putting them into the destination. Clearly, ColorSync should call CMMatchPixmap in this case. He also said that he implemented CMMatchPixmap, yet it never gets called during a DrawMatchedPicture playback. It is called when he calls CWMatchPixMap from the low-level interface.
If this is true, it would explain his findings, since converting the pixmap to
RGBColors and back again takes time and memory. Also, any cacheing performed by
the CMM would probably be less efficient. I would like your opinion on this
issue. Is there a performance problem with DrawMatchedPicture that can be
overcome by using the suggested procedure? If his information is accurate, is
this fixed in ColorSync 2.0 ?
A Surprising as it may be, it's more efficient for printer drivers to manually
match colors inside Stdxxx bottlenecks, instead of calling DrawMatchedPicture.
This is because ColorSync 1.0 DrawMatchedPicture does not use bottlenecks as
you expected. It does install a bottleneck routine for PicComments (so that it
can watch the embedded profiles go by), but it doesn't do the actual matching
in bottleneck routines. Instead, it installs a ColorSearchProc in the current
GDevice. Inside the ColorSearchProc, each color is matched one at a time.
While this implementation has some advantages, it's also painfully slow on
PixMaps, because, even if the PixMap only contains 16 colors, each pixel is
matched. This has been changed in CS 2.0. To boost performance, PixMaps (which
are, after all, quite common), are now matched in the bottleneck instead of in
ColorSearchProc.